1. Field of the Invention
The invention relates to a method for verifying the processing of an automation task in the form of software in a multi-channel safety-oriented automation component.
2. Discussion of Background Information
Whenever electronic automation components, such as e.g., control devices, actuator, sensors, etc., are employed to perform tasks of personal protection, these components must meet stringent requirements. An essential aspect of these requirements involve designing the automation components to be sufficiently robust so that no conditions can arise which would endanger any persons in the vicinity of the automation components if any defects occur in the automation components. Electronic automation components of this type are typically provided with a diagnostic function in order to meet these requirements. The job of this diagnostic function is to detect any possible errors in the active unit of the automation component and to deactivate those elements of the automation component that are affected by the errors, or to initiate another safety-oriented action. An active unit is understood to refer to a component that processes data, makes calculations, etc., that is, typically units like processors, arithmetic units, programmable logic controllers, etc. Safety-relevant functions in an automation component are usually also implemented-in a multi-channel design in order to achieve the required safety level, e.g., an SIL (safety integrity level) complying with IEC 61508 or other standards. In a multi-channel design a safety-relevant function is provided in multiple form, and a calculation of the function is only considered to be valid if all channels supply the same result.
For developing safety-oriented automation systems or automation components so-called Failure Mode and Effects Analysis (FMEA) are implemented. These are analytical methods that are known per se for finding potential weak points and have the goal of precluding errors and enhancing technical reliability.
The diagnostic function in an automation component is generally designed to diagnose and recognize possible errors that are determined e.g. in the course of the system design in an FMEA. The diagnostics routines are implemented statically in the automation component in separate diagnostics processors and not adapt, or only poorly adapt, themselves to the application-specific environment in the active unit of the automation component. Whenever complex electronic modules, such as, for example, processors are used in the automation component, comprehensive and expensive diagnostics functions are required, such as e.g., op-code tests and register tests. As the complexity of the processor used and/or software running thereon increases in complexity, it becomes more and more difficult to properly implement the diagnostics in the automation component. Furthermore the diagnostics cannot be implemented for all possible applications of an automation component, with the result that the diagnostics cannot provide one-hundred-percent safety and reliability.
As a result, the channels of a safety-oriented multi-channel automation component are implemented using a diversity scheme—either through diversity hardware or diversity software. Diversity in the technical context means that a system or a function is implemented redundantly, where deliberately different implementations of the system or of the function are used. Consequently the various channels of the multi-channel automation component here are implemented differently, that is, with different hardware or different software. An automation task is thus performed in the automation component using different hardware or different software and the different implementations of the automation task must deliver the same results if there are no errors.
Using diversity hardware (see FIG. 1) requires that processors having different processor cores must be used in the various channels. However, the current trend among processor manufacturers is in a completely different direction, in particular, towards focusing on as few different processor cores as possible. Many manufacturers producing processors for the embedded segment, such as those that are also employed in automation components, are using what are known as ARM (Advanced RISC Machines) cores in their products, with the result that hardware diversity is then possible only by using “exotic” processors. Of course “exotic” processors are not in widespread use and thus have no real proven track record, a factor that is also a critical aspect in terms of applications in safety-oriented automation components in the area of personal safety. The trend for safety-oriented automation components is thus toward homogeneous hardware.
An alternative solution approach is therefore to design the diversity scheme into the software (see FIG. 2). This enables errors in the processor core or memory to be detected with sufficiently high probability. Diversity software has the disadvantage, however, that the run time can vary considerably on the different channels. The performance of the automation components of a multi-channel system is, however, governed by the slowest channel since the result found is valid only after the data have been compared.